In recent years, content distribution services have been provided. In the content distribution services, content playback devices make requests for contents, and in response, content transmission devices distribute the requested contents to the content playback devices. In such distribution services, contents are encrypted to protect their copyrights, and the encrypted contents are transmitted via a wired LAN conforming to IEEE 802.3, a wireless LAN conforming to IEEE 802.11, and the like.
When transmitting/receiving contents in the above manner, a DTCP (Digital Transmission Content Protection) is utilized as one technique to protect copyrights of the contents.
DTCP is technology for protecting contents on transmission media such as those specified in IEEE 1394 and a USB (Universal Serial Bus). DTCP is also a method standardized by the DTLA (Digital Transmission Licensing Administrator), LLC. Each device holds a device certificate issued by the DTLA, LLC. Upon transmission of content, a receiving device and a transmitting device authenticate each other's device certificates and perform key exchange. This process for authentication and key exchange is referred to as AKE (Authentication and Key Exchange). This way, multiple devices can share an encryption key, and thus perform a network transmission while protecting the contents.
DTCP has been expanded so it can be used on the IP (Internet Protocol) network. The expanded DTCP is referred to as DTCP-IP.
When performing normal playback according to DTCP-IP, a sink device (i.e., a content requesting side) outputs a single content acquisition request, which indicates acquisition of one content in its entirety, to a source device (i.e., a content transmitting side). The source device divides the entire content that has been requested into a plurality of content portions, then encrypts and transmits each of the content portions. The size of each content portion is 128 MB. For each content portion, the source device updates a nonce Nc, which is a parameter used when generating a content key, by adding “1” to the nonce Nc. As a result, a content key is generated for each content portion by using the updated nonce Nc, and each content portion is encrypted using the generated content key. That is to say, a content key that is used to encrypt one content portion is different from any of content keys that are used to encrypt other content portions. With this technique, even if a content key used to encrypt one content portion is leaked, this leak does not progress to leak of content keys for other content portions. Consequently, the security of other content portions can be preserved.
According to DTCP-IP, in order to confirm a content key, the source device checks a nonce NcT that has been received from the sink device in connection with the current nonce Nc of the source device. The current nonce Nc of the source device is considered normal if it falls within a range of NcT to NcT+5 inclusive.
Generally, a device that plays pack contents has a normal playback function for performing playback at a normal speed, as well as a special playback function for performing special playback such as fast-forwarding and fast-rewinding. When performing special playback such as fast-forwarding and fast-rewinding in accordance with DTCP-IP, the sink device outputs to the source device a plurality of content acquisition requests in succession within a short period of time. The content acquisition requests are requests for acquisition of respective portions of content. As a result of the plurality of content acquisition requests having been output in succession within a short period of time, the source device transmits portions of the content requested by the respective content acquisition requests to the sink device. In this manner, fast-forwarding and fast-rewinding can be achieved.
In this case, the source device updates a nonce Nc each time it receives a single content acquisition request, as with the case where content is requested in its entirety. As a result, during the special playback, the nonce Nc is frequently updated in the source device within a short period of time. This may lead to a situation where the nonce Nc does not fall within a normal range and therefore content key confirmation processing fails. In such a situation, decryption must be halted.
In order to solve the above problem, Patent Literature 1 discloses technology for, when performing special playback, reducing the frequency of content requests that cause updates of a content key, or bringing a halt to the next content request, until the content key confirmation processing completes.